Scan content of $CARGO_HOME/bin on restore instead of relying on cargo install metadata #325
Merged
Swatinem merged 1 commit intoApr 12, 2026
Conversation
Instead of relying on `.crates2.json` to know which binaries are installed, scan the bin directory and save the result in the action's state.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
|
|
||
| - run: rustup toolchain install stable --profile minimal --no-self-update | ||
|
|
||
| - uses: cargo-bins/cargo-binstall@v1.17.9 |
Contributor
Author
There was a problem hiding this comment.
In case this helps, that tag is linked to an immutable release and it therefore cannot be modified. That is why I pinned it there; otherwise I would've pinned to a commit hash.
Swatinem
reviewed
Apr 10, 2026
Comment on lines
+33
to
+34
| env: | ||
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} |
Owner
There was a problem hiding this comment.
why does this need the github token? I couldn’t find any docs that mention this, and I would prefer to rather remove this.
Contributor
Author
There was a problem hiding this comment.
It's not strictly required, but if cargo-binstall downloads binaries from GitHub, it will try to use a GitHub token to avoid hitting more stringent API rate limits. It's possible to pass --github-token on the command-line, otherwise the fallback is to check the GITHUB_TOKEN environment variable.
This is documented in HELP.md, although admittedly not that clearly.
Before I added this, I often hit rate limits in my CI workflows. It's possible that yours wouldn't be that affected, however.
Owner
There was a problem hiding this comment.
Thanks for the explanation. This looks good to me.
francisdb
added a commit
to francisdb/vpin
that referenced
this pull request
May 14, 2026
The new GitHub macOS runner image (actions/runner-images#14037) ships a rustup layout where $CARGO_HOME/bin contains proxies that, once round- tripped through rust-cache's bin scanner (introduced in v2.9.0 by Swatinem/rust-cache#325), restore as aliases to `rustup-init`. After cache restore, `cargo build` then dispatches as `rustup-init` and dies with "unexpected argument 'build'". Setting cache-bin: false on the build matrix step keeps the toolchain proxies installed by dtolnay/rust-toolchain intact across runs. Only applied to the build matrix; the wasm jobs legitimately want bin caching for their `cargo install wasmtime-cli` / `cargo install wasm-bindgen-cli` steps and aren't affected (they run on ubuntu-latest). See Swatinem/rust-cache#341
pull Bot
pushed a commit
to thompson-tomo/otel-arrow
that referenced
this pull request
May 15, 2026
…cos-latest (open-telemetry#2978) ## Problem CI `clippy (*, macos-latest)` (and other macOS rust steps) started failing today across many PRs with: ``` error: error: unexpected argument 'clippy' found Usage: rustup-init[EXE] [OPTIONS] ``` ## Root cause GitHub rolled out a new macos-latest runner image today ([actions/runner-images#14037](actions/runner-images#14037)) that changed how the `rustc`/`cargo` rustup proxy binaries are set up. Combined with [Swatinem/rust-cache#325](Swatinem/rust-cache#325) (which made `cache-bin: true` the default in v2.8+), the cached `$CARGO_HOME/bin/` from previous runs gets restored over the freshly-installed proxies, leaving `cargo` dispatching to `rustup-init` behavior instead of the real cargo. Tracked upstream: [Swatinem/rust-cache#341](Swatinem/rust-cache#341). ## Fix Set `cache-bin: false` on all 7 `Swatinem/rust-cache` invocations in `.github/workflows/rust-ci.yml`. This is the workaround confirmed by the upstream issue reporter. We don't `cargo install` any binaries that need caching, so this loses no useful caching.
3 tasks
Merged
2 tasks
guancioul
pushed a commit
to guancioul/otel-arrow
that referenced
this pull request
May 16, 2026
…cos-latest (open-telemetry#2978) ## Problem CI `clippy (*, macos-latest)` (and other macOS rust steps) started failing today across many PRs with: ``` error: error: unexpected argument 'clippy' found Usage: rustup-init[EXE] [OPTIONS] ``` ## Root cause GitHub rolled out a new macos-latest runner image today ([actions/runner-images#14037](actions/runner-images#14037)) that changed how the `rustc`/`cargo` rustup proxy binaries are set up. Combined with [Swatinem/rust-cache#325](Swatinem/rust-cache#325) (which made `cache-bin: true` the default in v2.8+), the cached `$CARGO_HOME/bin/` from previous runs gets restored over the freshly-installed proxies, leaving `cargo` dispatching to `rustup-init` behavior instead of the real cargo. Tracked upstream: [Swatinem/rust-cache#341](Swatinem/rust-cache#341). ## Fix Set `cache-bin: false` on all 7 `Swatinem/rust-cache` invocations in `.github/workflows/rust-ci.yml`. This is the workaround confirmed by the upstream issue reporter. We don't `cargo install` any binaries that need caching, so this loses no useful caching.
guancioul
pushed a commit
to guancioul/otel-arrow
that referenced
this pull request
May 16, 2026
…cos-latest (open-telemetry#2978) ## Problem CI `clippy (*, macos-latest)` (and other macOS rust steps) started failing today across many PRs with: ``` error: error: unexpected argument 'clippy' found Usage: rustup-init[EXE] [OPTIONS] ``` ## Root cause GitHub rolled out a new macos-latest runner image today ([actions/runner-images#14037](actions/runner-images#14037)) that changed how the `rustc`/`cargo` rustup proxy binaries are set up. Combined with [Swatinem/rust-cache#325](Swatinem/rust-cache#325) (which made `cache-bin: true` the default in v2.8+), the cached `$CARGO_HOME/bin/` from previous runs gets restored over the freshly-installed proxies, leaving `cargo` dispatching to `rustup-init` behavior instead of the real cargo. Tracked upstream: [Swatinem/rust-cache#341](Swatinem/rust-cache#341). ## Fix Set `cache-bin: false` on all 7 `Swatinem/rust-cache` invocations in `.github/workflows/rust-ci.yml`. This is the workaround confirmed by the upstream issue reporter. We don't `cargo install` any binaries that need caching, so this loses no useful caching.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The current implementation of
getCargoBinsto check which binary is installed in$CARGO_HOME/binchecks the content of$CARGO-HOME/.crates2.jsonto determine which binary is preinstalled. When saving cache, all binaries not found in that file are removed to avoid caching them.This means, however, that anything installed via a mean other than
cargo install(like for example viacargo-binstall) won't be cached.This PR changes the logic: now, when restoring cache, the
$CARGO_HOME/bindirectory is scanned and all files there are kept in the action state. When saving the cache post-install, all binaries that were in the directory at the beginning are removed; all others are cached. This allows the use of something likecargo-binstallortaiki-e/install-action, while still benefiting from caching.I've also added a new workflow to test with
cargo-binstall.Let me know if there's something I should update as well.